The invention relates to a method, a system, a computer program and a computer-readable storage medium for ascertaining a fault tree for a technical system.
Such a method and such a system are known from N. Leveson, Safety verification of ADA-Programs using Software Fault Trees, IEEE Software, pages 48–59, July 1991 (“Leveson”).
Leveson discloses the practice of using computers to ascertain a fault tree for a computer program. For the computer program, a control flow description is ascertained in the form of a control flowchart. For various program elements of the computer program, a stored fault description associated with a respective stored reference element is used to ascertain an element fault description. The fault description for a reference element describes possible faults for the respective reference element. The element fault descriptions in the form of element fault trees are used to ascertain the fault tree, taking into account the control flowchart.
The method and the system from Leveson have the following drawbacks, in particular. The fault tree ascertained is incomplete in terms of the faults examined and the causes thereof, and is therefore unreliable. Hence, this practice is not appropriate for use within the context of generating fault trees for safety-critical applications. The individual fault trees associated with the reference elements are also incomplete and hence unreliable.
DIN 25424-1: Fehlerbaumanalysen; Methoden und Bildzeichen (Fault Tree Analyses; Methods and Graphic Symbols), September 1981 (“DIN '424-1”) discloses principles relating to a fault tree. A fault tree is to be understood, as described in DIN '424-1, to mean a structure which describes logical relationships between input variables for the fault tree, which input variables lead to a prescribed and desirable result.
In addition, DIN 25424-2: Fehlerbaumanalyse; Handrechenverfahren zur Auswertung eines Fehlerbaums (Fault Tree Analysis; Manual Computation Methods for Evaluating a Fault Tree), Berlin, Beuth Verlag GmbH, April 1990 discloses various methods for fault tree analysis.
Further, H. Zebedin, FMEA aus Sicht eines Motorenentwicklers, Qualität und Zuverlässigkeit (FMEA from the Angle of a Motor Developer, Quality and Reliability), QZ 43, pp. 826 ff., Carl Hanser Verlag, Munich, 1998 discloses principles relating to “failure modes and effects [and criticality] analysis” (FME[C]A) for a technical system. The aim of failure modes and effects analysis is to recognize risks and problem areas in a technical system, to identify fault potentials, to quantify risks and to reduce work regarding mistakes. As is evident, failure modes and effects analysis is a method for spotting faults in the hardware and software design and development phase. Faults possibly underlying a technical system are listed manually and effects of the respective fault occurring are determined, normally including the damage which may arise on account of the fault. In addition, failure modes and effects analysis includes highlighting possible measures for preventing the respective fault. Failure modes and effects analysis is particularly suitable for documenting and transferring technical knowledge, for example in service sectors for maintaining a technical system. A distinction is drawn between design-related failure modes and effects analysis and process-related failure modes and effects analysis. In the case of design-related failure modes and effects analysis, individual components of the technical system are examined for incorrect action by them. The content of process-related failure modes and effects analysis is a technical system's development and manufacturing process. If failure modes and effects analysis involves examining not just the individual components of the technical system, but also the relationships between the malfunctions of the components in the entire system, then the failure modes and effects analysis is referred to as system-related failure modes and effects analysis. Process-related failure modes and effects analysis may extend into system-related failure modes and effects analysis if effects of faults in the production process appear as causes of faults in the system-related failure modes and effects analysis (for example lines rubbing on moving parts on account of missing cable ties).
System-related failure modes and effects analysis makes it possible to use the cause/effect relationships between the components of the technical system to build fault chains which can be represented in the form of fault networks.
To perform system-related failure modes and effects analysis, the following steps are normally carried out:
1. Define System Components and System Structure
The system to be examined is broken down into its components. The components are in turn broken down into subcomponents, which gives a hierarchical relationship between the individual components which respectively indicates which subcomponents a component in the technical system comprises. The components of the technical system are also referred to as structural elements of the technical system. A structure tree is ascertained on the basis of the relationships between the components.
2. Define Functions of the Components
The function of each component defined in the system structure is described. In this context, the function of a subcomponent is a subfunction of the respective superordinate component.
3. Perform Fault Analysis
Every function of a component has corresponding malfunctions associated with it which describe faults which may occur with the component. The effects of the faults can then be found as a malfunction in the respective superordinate component. The causes of faults in a component are listed as malfunctions in the subcomponents.
4. Risk assessment
With failure modes and effects analysis, a risk of a fault is expressed by a risk priority number (RPN).RPN=B×A×E, 
where                B denotes a significance of the fault, with a range of [1, 10] normally being used (a value of 1 denotes an insignificant fault and a value of 10 denotes a very significant fault with respect to a prescribed criterion);        A denotes a frequency of occurrence of the fault, again using a range of [1, 10], where a value of 1 denotes a very low frequency of occurrence and a value of 10 denotes a very high frequency of occurrence;        E denotes a likelihood of the fault being discovered, said likelihood being able to adopt a value between [1, 10], where a value of 1 indicates that the fault is always discovered and a value of 10 indicates that the fault generally remains undiscovered.        
1. Improving the System
On the basis of the evaluation of the RPN, alterations should be made to the technical system.
For computer-assisted implementation of failure modes and effects analysis, Information zum Werkzeug IQ-FMEA (Information relating to the IQ-FMEA Tool), APIS Informationstechnologien GmbH, Jena, 1998 discloses a computer program which is referred to below as IQ-FMEA. IQ-FMEA contains both a structure editor and a function editor, and a fault analysis editor. These editors are used to describe a hierarchical structure for the technical system. This structure comprises the components and the functions and malfunctions thereof. In addition, IQ-FMEA contains a “form editor”, which allows possible faults, causes of faults, effects of faults and preventive measures to be documented for the respective component in the technical system.
A drawback of the manually produced failure modes and effects analysis and also of possible manual creation of a fault tree is, in particular, the unreliability of the fault description obtained from the failure modes and effects analysis and manual creation of the fault tree. Particularly in the case of safety-critical technical systems, this results in an intolerable risk in the assessment of possible faults which can occur in the technical system.